Skip to content

fix: improve handling of lines starting with a kanji (#3821)#3822

Open
d0gkiller87 wants to merge 2 commits intospicetify:mainfrom
d0gkiller87:lyrics-plus-furigana-fix
Open

fix: improve handling of lines starting with a kanji (#3821)#3822
d0gkiller87 wants to merge 2 commits intospicetify:mainfrom
d0gkiller87:lyrics-plus-furigana-fix

Conversation

@d0gkiller87
Copy link
Copy Markdown

@d0gkiller87 d0gkiller87 commented Apr 18, 2026

fix for issue #3821

image

Summary by CodeRabbit

  • Bug Fixes
    • More accurate lyrics text normalization to avoid false triggers of "translated-below" display and to make copy/clipboard behavior more reliable across varied lyric formats.
    • Improved ruby text rendering to avoid inserting empty elements, resulting in cleaner displayed text and more stable rendering.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 18, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 31efc140-db39-4746-9de8-f31916e44eea

📥 Commits

Reviewing files that changed from the base of the PR and between 5cdacf7 and 2faa53d.

📒 Files selected for processing (1)
  • CustomApps/lyrics-plus/Utils.js
🚧 Files skipped from review as they are similar to previous changes (1)
  • CustomApps/lyrics-plus/Utils.js

📝 Walkthrough

Walkthrough

Updated lyric text handling: three memoized page components now use type-aware normalization when deriving comparison text; ruby-to-React conversion no longer inserts an empty initial child when the pre-ruby segment is empty.

Changes

Cohort / File(s) Summary
Lyrics Text Comparison Logic
CustomApps/lyrics-plus/Pages.js
Replaced uniform extraction of lyric text with type-aware handling in SyncedLyricsPage, SyncedExpandedLyricsPage, and UnsyncedLyricsPage: strings are normalized directly; non-string text only yields text.props.children[0] if that child is a string, otherwise "". This alters belowTxt/belowMode determination.
Ruby Text Rendering
CustomApps/lyrics-plus/Utils.js
In rubyTextToReact, only append the pre-<ruby> segment (rubyElems[0]) when it is non-empty to avoid inserting an empty child into the React children array.

Sequence Diagram(s)

(omitted — changes are focused, not introducing new multi-component control flow)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related issues

Suggested reviewers

  • rxri

Poem

🐰 Soft paws tap the keys,

Lines tidy up with ease,
Empty bits hop away,
Ruby and text now play,
I nibble bugs and hum a breeze 🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: improving handling of lines starting with a kanji character, which is the core of the furigana/ruby text processing fixes made to the lyrics-plus component.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
CustomApps/lyrics-plus/Utils.js (1)

178-186: ⚠️ Potential issue | 🟡 Minor

Fix biome formatting failure and apply the same empty-string guard to the trailing segment.

Two things on this block:

  1. CI is failing on biome formatting for this file. The new if uses single quotes and omits braces, which is inconsistent with the rest of the file (tabs + double quotes + braced bodies). Reformatting should clear the pipeline failure.
  2. The symmetric case on line 185 — rubyElems[i].split("</ruby>")[1] — pushes an empty string when a line ends with </ruby> (i.e. no trailing text after the last ruby). That yields the same kind of empty leading/trailing child in p1.props.children that the new guard is avoiding at the start, so belowTxt extraction in Pages.js can still misbehave depending on which end is affected. Worth guarding both ends the same way.
Proposed fix
-		if (rubyElems[0] !== '')
-			reactChildren.push(rubyElems[0]);
+		if (rubyElems[0] !== "") {
+			reactChildren.push(rubyElems[0]);
+		}
 		for (let i = 1; i < rubyElems.length; i++) {
 			const kanji = rubyElems[i].split("<rp>")[0];
 			const furigana = rubyElems[i].split("<rt>")[1].split("</rt>")[0];
 			reactChildren.push(react.createElement("ruby", null, kanji, react.createElement("rt", null, furigana)));
-
-			reactChildren.push(rubyElems[i].split("</ruby>")[1]);
+			const trailing = rubyElems[i].split("</ruby>")[1];
+			if (trailing !== "") {
+				reactChildren.push(trailing);
+			}
 		}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@CustomApps/lyrics-plus/Utils.js` around lines 178 - 186, The if statement and
trailing push in the loop need to match file formatting and avoid empty-string
children: change the new guard to use the file's style (tabs, double quotes,
braced body) and add a symmetric empty-string check before pushing the trailing
segment (the result of rubyElems[i].split("</ruby>")[1]); locate the block using
symbols rubyElems, reactChildren and react.createElement and ensure you only
push the trailing part when it's not "" so both leading and trailing empty
children are prevented.
🧹 Nitpick comments (1)
CustomApps/lyrics-plus/Pages.js (1)

311-320: Deduplicate belowTxt / belowOrigin extraction across the three pages.

The same nested-ternary for belowTxt is repeated verbatim at lines 313-318, 642-647, and 726-731, and the belowOrigin expression on line 312 (and 641, 725) still uses the old text?.props?.children?.[0] pattern without the new "only if string" guard. That asymmetry means if originalText is ever a React element whose first child is not a string (e.g. a ruby element when the original itself starts with kanji — same shape produced by rubyTextToReact after this PR's change), .replace will be invoked on a non-string and throw or silently misbehave.

Extracting a small helper keeps both sides consistent and makes the fix a single point of change:

Proposed refactor
+const toComparableText = (value) => {
+	if (typeof value === "string") return value.replace(/\s+/g, "");
+	const first = value?.props?.children?.[0];
+	return typeof first === "string" ? first.replace(/\s+/g, "") : "";
+};

Then in each of the three pages:

-				// Convert lyrics to text for comparison
-				const belowOrigin = (typeof originalText === "object" ? originalText?.props?.children?.[0] : originalText)?.replace(/\s+/g, "");
-				const belowTxt =
-					typeof text === "string"
-						? text.replace(/\s+/g, "")
-						: typeof text?.props?.children?.[0] === "string"
-							? text.props.children[0].replace(/\s+/g, "")
-							: "";
+				// Convert lyrics to text for comparison
+				const belowOrigin = toComparableText(originalText);
+				const belowTxt = toComparableText(text);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@CustomApps/lyrics-plus/Pages.js` around lines 311 - 320, Create a small
helper (e.g., extractPlainText or getTextContent) that takes a value which can
be a string or a React element and returns a string with all whitespace removed
(use .replace(/\s+/g, "") only when the final value is a string); then replace
the repeated nested-ternaries that compute belowOrigin and belowTxt with calls
to that helper and compute belowMode using showTranslatedBelow && originalText
&& belowOrigin !== belowTxt so all three pages use the same safe extraction
logic (ensure the helper checks typeof value === "string" first, then inspects
value?.props?.children?.[0] only if that child is a string).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@CustomApps/lyrics-plus/Utils.js`:
- Around line 178-186: The if statement and trailing push in the loop need to
match file formatting and avoid empty-string children: change the new guard to
use the file's style (tabs, double quotes, braced body) and add a symmetric
empty-string check before pushing the trailing segment (the result of
rubyElems[i].split("</ruby>")[1]); locate the block using symbols rubyElems,
reactChildren and react.createElement and ensure you only push the trailing part
when it's not "" so both leading and trailing empty children are prevented.

---

Nitpick comments:
In `@CustomApps/lyrics-plus/Pages.js`:
- Around line 311-320: Create a small helper (e.g., extractPlainText or
getTextContent) that takes a value which can be a string or a React element and
returns a string with all whitespace removed (use .replace(/\s+/g, "") only when
the final value is a string); then replace the repeated nested-ternaries that
compute belowOrigin and belowTxt with calls to that helper and compute belowMode
using showTranslatedBelow && originalText && belowOrigin !== belowTxt so all
three pages use the same safe extraction logic (ensure the helper checks typeof
value === "string" first, then inspects value?.props?.children?.[0] only if that
child is a string).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9e26eabc-eec7-4393-a5b5-d7faca33d662

📥 Commits

Reviewing files that changed from the base of the PR and between 660a191 and 5cdacf7.

📒 Files selected for processing (2)
  • CustomApps/lyrics-plus/Pages.js
  • CustomApps/lyrics-plus/Utils.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant